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The Name Service Search Option for DHCP 
Status of this Memo 


This document specifies an Internet standards track protocol for the 
Internet community, and requests discussion and suggestions for 


improvements. Please refer to the current edition of the "Internet 
Official Protocol Standards" (STD 1) for the standardization state 
and status of this protocol. Distribution of this memo is unlimited. 


Copyright Notice 
Copyright (C) The Internet Society (2000). All Rights Reserved. 
Abstract 
This document defines a new Dynamic Host Configuration Protocol 
(DHCP) option which is passed from the DHCP Server to the DHCP Client 


to specify the order in which name services should be consulted when 
resolving hostnames and other information. 


Introduction 


The Dynamic Host Configuration Protocol (DHCP) [1] provides a 
framework for passing configuration information to hosts on a TCP/IP 
network. RFC 2132 [2] allows DHCP servers to specify configuration 
information for various kinds of name services to be passed to DHCP 
clients. Many clients use multiple name services and have crafted 
their own conventions that allow an individual host to express the 
order among the various name services with which lookups are done. 


However, no search order can be specified via DHCP. The purpose of 
this document is to allow DHCP servers to specify the search order to 
be used by DHCP clients. To avoid the need for inventing and 


maintaining a separate name space for this option, we rely on the 
existence of previously-defined DHCP options that specify the IP 
address(es) of servers which provide name services whose order we 
wish to express. 
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Definitions 
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", “SHALL NOT", 
"SHOULD", “SHOULD NOT", "RECOMMENDED", "MAY" and "OPTIONAL" in this 
document are to be interpreted as described in RFC 2119 [3]. This 
document also uses the following terms: 


"DHCP client" 


DHCP client or "client" is an Internet host using DHCP to 
obtain configuration parameters such as a network address. 


"DHCP server" 


A DHCP server or "server" is an Internet host that returns 
configuration parameters to DHCP clients. 


Name Service Search Option Format 


The code for this option is 117, and its minimum length is 2 bytes. 
A DHCP server SHOULD return, in its preferred order, the 16-bit, 


network byte order (big-endian [4]) integer option code for the 
name services (the earlier in the list, the more preferred the name 
service). 
Code Length Name Service Search Order in Sequence 
0 1 2 3 


012345678901234567890123456789021 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| 7 | Len | nsl | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| ns2 | see | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
In the above diagram, nsl and ns2 are 16-bit integers corresponding 
to two DHCP options which specify the IP addresses of two different 
types of name server. The current list of name services and their 
DHCP option codes, taken from RFC 2132, includes 


Name Service Value 
Domain Name Server Option 6 
Network Information Servers Option 41 
NetBIOS over TCP/IP Name Server Option 44 
Network Information Service+ Servers Option 65 
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A name service option code of 0 is used to indicate that the 
client should refer to local naming information (e.g., an 
/etc/hosts file on a UNIX machine). 


A DHCP server wishing to express that a client should first search 
DNS, then NIS+, would send 


0 1 2 3 
01234567890123456789012345678901 
$oF-F FH ti tipi pi pip gigi p it titi tipi pepe g ip gt titi ti gig 
| 117 | 4 | 6 | 
$oF-F Fata tipi pi pip gigi tit iti titi pi pipe pgp HHHH 
| 65 | 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++ 


DHCP Client Behavior 


The DHCP client will use this option to create a search list for 
name resolution. The client may receive name services in this 
option that it does not support or has not been configured to 
access. Likewise, a client may receive an option that lists name 
services for which no corresponding DHCP option was supplied. 
Clients will interpret this option in a system-specific manner 
whose specification is outside the scope of this document. 


Security Considerations 


DHCP currently provides no authentication or security mechanisms. 
Potential exposures to attack are discussed in section 7 of the DHCP 
protocol specification [1]. 


IANA Considerations 


IANA has assigned a value of 117 for the DHCP option code described 
in this document. 
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Full Copyright Statement 
Copyright (C) The Internet Society (2000). All Rights Reserved. 


This document and translations of it may be copied and furnished to 
others, and derivative works that comment on or otherwise explain it 
or assist in its implementation may be prepared, copied, published 
and distributed, in whole or in part, without restriction of any 
kind, provided that the above copyright notice and this paragraph are 
included on all such copies and derivative works. However, this 
document itself may not be modified in any way, such as by removing 
the copyright notice or references to the Internet Society or other 
Internet organizations, except as needed for the purpose of 
developing Internet standards in which case the procedures for 
copyrights defined in the Internet Standards process must be 
followed, or as required to translate it into languages other than 
English. 


The limited permissions granted above are perpetual and will not be 
revoked by the Internet Society or its successors or assigns. 


This document and the information contained herein is provided on an 
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 
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